Network Working Group 


Request for Comments: 1115 


J. Linn 

DEC 

IAB Privacy Task Force 
August 1989 


Privacy Enhancement for Internet Electronic Mail: 


Part III -- Algorithms, Modes, 


STATUS OF THIS MEMO 


and Identifiers 


This RFC suggests a draft standard elective protocol for the Internet 


community, and requests discussion and suggestions for improvement. 
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Executive Summary 


This RFC provides definitions, references, and citations for algorithms, 
usage modes, and associated identifiers used in RFC-1113 and RFC-1114 
in support of privacy-enhanced electronic mail in the Internet 
community. As some parts of this material are cited by both RFC-1113 
and RFC-1114, and as it is anticipated that some of the definitions 
herein may be changed, added, or replaced without affecting the citing 
RFCs, algorithm-specific material has been placed into this separate 
RFC. The text is organized into three primary sections; dealing with 
symmetric encryption algorithms, asymmetric encryption algorithms, and 
integrity check algorithms. 


Symmetric Encryption Algorithms and Modes 


This section identifies alternative symmetric encryption algorithms 
and modes which may be used to encrypt DEKs, MICs, and message text, 
and assigns them character string identifiers to be incorporated in 
encapsulated header fields to indicate the choice of algorithm 
employed. (Note: all alternatives presently defined in this category 
correspond to different usage modes of the DEA-1 (DES) algorithm, 
rather than to other algorithms per se.) 


DES Modes 


The Block Cipher Algorithm DEA-1, defined in ANSI X3.92-1981 [3] may 
be used for message text, DEKs, and MICs. The DEA-1 is equivalent to 
the Data Encryption Standard (DES), as defined in FIPS PUB 46 [4]. 

The ECB and CBC modes of operation of DEA-1 are defined in ISO IS 8372 
[5]. 


1. DES in ECB mode (DES-ECB) 
The string "DES-ECB" indicates use of the DES algorithm in Electronic 
Codebook (ECB) mode. This algorithm/mode combination is used for DEK 


and MIC encryption. 


.2. DES in EDE mode (DES-EDE) 


The string "DES-EDE" indicates use of the DES algorithm in 
Encrypt-Decrypt-Encrypt (EDE) mode as defined by ANSI X9.17 [2] for 
key encryption and decryption with pairs of 64-bit keys. This 
algorithm/mode combination is used for DEK and MIC encryption. 
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2.1.3. DES in CBC mode (DES-CBC) 


The string "DES-CBC" indicates use of the DES algorithm in Cipher 
Block Chaining (CBC) mode. This algorithm/mode combination is used 
for message text encryption only. The CBC mode definition in IS 8372 
is equivalent to that provided in FIPS PUB 81 [6] and in ANSI X3.106- 
1983 [7]. 


3. Asymmetric Encryption Algorithms and Modes 


This section identifies alternative asymmetric encryption algorithms and 
modes which may be used to encrypt DEKs and MICs, and assigns them 
character string identifiers to be incorporated in encapsulated 

header fields to indicate the choice of algorithm employed. (Note: 

only one alternative is presently defined in this category.) 


3.1. RSA 


The string "RSA" indicates use of the RSA public-key encryption 
algorithm, as described in [8]. This algorithm is used for DEK and 
MIC encryption, in the following fashion: the product n of a 
individual's selected primes p and q is used as the modulus for the 
RSA encryption algorithm, comprising, for our purposes, the 
individual's public key. A recipient's public key is used in 
conjunction with an associated public exponent (either 3 or 1+2**16) 
as identified in the recipient's certificate. 


When a MIC must be padded for RSA encryption, the MIC will be 
right-justified and padded on the left with zeroes. This is also 
appropriate for padding of DEKs on singly-addressed messages, and for 
padding of DEKs on multi-addressed messages if and only if an exponent 
of 3 is used for no more than one recipient. On multi-addressed 
messages in which an exponent of 3 is used for more than one recipient, 
it is recommended that a separate 64-bit pseudorandom quantity be 
generated for each recipient, in the same manner in which IVs are 
generated. (Reference [9] discusses the rationale for this 
recommendation.) At least one copy of the pseudorandom quantity should 
be included in the input to RSA encryption, placed to the left of the 
DEK. 


4. Integrity Check Algorithms 


This section identifies the alternative algorithms which may be used 
to compute Message Integrity Check (MIC) and Certificate Integrity 
Check (CIC) values, and assigns the algorithms character string 
identifiers for use in encapsulated header fields and within 
certificates to indicate the choice of algorithm employed. 
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MIC algorithms which utilize DEA-1 cryptography are computed using a key 
which is a variant of the DEK used for message text encryption. The 
variant is formed by modulo-2 addition of the hexadecimal quantity 
FOFOFOFOFOFOFOFO to the encryption DEK. 


For compatibility with this specification, a privacy-enhanced mail 
implementation must be able to process both MAC (Section 2.1) and 
RSA-MD2 (Section 2.2) MICs on incoming messages. It is a sender option 
whether MAC or RSA-MD2 is employed on an outbound message addressed to 
only one recipient. However, use of MAC is strongly discouraged for 
messages sent to more than a single recipient. The reason for this 
recommendation is that the use of MAC on multi-addressed mail fails to 
prevent other intended recipients from tampering with a message in a 
manner which preserves the message's appearance as an authentic message 
from the sender. In other words, use of MAC on multi-addressed mail 
provides source authentication at the granularity of membership in the 
message's authorized address list (plus the sender) rather than at a 
finer (and more desirable) granularity authenticating the individual 
sender. 


4.1. Message Authentication Code (MAC) 


A message authentication code (MAC), denoted by the string "MAC", is 
computed using the DEA-1 algorithm in the fashion defined in FIPS PUB 
113 [1]. This algorithm is used only as a MIC algorithm, not as a CIC 
algorithm. 


As noted above, use of the MAC is not recommended for multicast 
messages, as it does not preserve authentication and integrity among 
individual recipients, i.e., it is not cryptographically strong enough 
for this purpose. The message's canonically encoded text is padded at 
the end, per FIPS PUB 113, with zero-valued octets as needed in order to 
form an integral number of 8-octet encryption quanta. These padding 
octets are inserted implicitly and are not transmitted with a message. 
The result of a MAC computation is a single 64-bit value. 


4.2. | RSA-MD2 Message Digest Algorithm 
4.2.1. Discussion 


The RSA-MD2 Message Digest Algorithm, denoted by the string "RSA-MD2", 
is computed using an algorithm defined in this section. It has been 
provided by Ron Rivest of RSA Data Security, Incorporated for use in 
support of privacy-enhanced electronic mail, free of licensing 
restrictions. This algorithm should be used as a MIC algorithm 
whenever a message is addressed to multiple recipients. It is also 
the only algorithm currently defined for use as CIC. While its 
continued use as the standard CIC algorithm is anticipated, RSA-MD2 
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may be supplanted by later recommendations for MIC algorithm 
selections. 


The RSA-MD2 message digest algorithm accepts as input a message of any 
length and produces as output a 16-byte quantity. The attached 
reference implementation serves to define the algorithm; implementors 
may choose to develop optimizations suited to their operating 
environments. 


4.2.2. Reference Implementation 


/* RSA-MD2 Message Digest algorithm in C */ 
/* by Ronald L. Rivest 10/1/88 */ 


#include <stdio.h> 


[RR KKK KKK KKK KKK KKK KK KK KR KK KK OK KK OK OK KK ck kck ck kck ck ckck ck ckckck ck OK / 


/* Message digest routines: sh 
/* To form the message digest for a message M */ 
/* (1) Initialize a context buffer md using MDINIT */ 
/* (2) Call MDUPDATE on md and each character of M in turn */ 
/* (3) Call MDFINAL on md ny 
/* The message digest is now in md->D[0...15] */ 
[RR KKK KKK KKK KKK KKK KK kk CK CK kk Sk KC Ck KK KK OK kck ck kckck ck kck ck kck ck kck ck ckckck ck ck kk / 
/* An MDCTX structure is a context buffer for a message digest */ 
/* computation; it holds the current "state" of a message digest Ly, 
/* computation he], 


struct MDCTX 
{ 
unsigned char D[48]; /* buffer for forming digest in */ 
/* At the end, D[0...15] form the message */ 
/* digest */ 


unsigned char C[16]; /* checksum register */ 
unsigned char i; /* number of bytes handled, modulo 16 */ 
unsigned char L; /* last checksum char saved */ 
}; 
/* The table S given below is a permutation of 0...255 constructed ef 
/* from the digits of pi. It is a "'random'' nonlinear byte */ 
/* substitution operation. * 


int S[256] = { 
41, 46, 67,201,162,216,124, 1, 61, 54, 84,161,236,240, 6, 19, 
98,167, 5,243,192,199,115,140,152,147, 43,217,188, 76,130,202, 
30,155, 87, 60,253,212,224, 22,103, 66,111, 24,138, 23,229, 18, 
190, 78,196,214,218,158,222, 73,160,251,245,142,187, 47,238,122, 
169,104,121,145, 21,178, 7, 63,148,194, 16,137, 11, 34, 95, 33, 
128,127, 93,154, 90,144, 50, 39, 53, 62,204,231,191,247,151, 3, 
255, 25, 48,179, 72,165,181,209,215, 94,146, 42,172, 86,170,198, 
79,184, 56,210,150,164,125,182,118,252,107,226,156,116, 4,241, 
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H; 


69,157,112, 89,100,113,135, 32,134, 91,207,101,230, 45,168, 
271, 96, 37,173,174,176,185,246, 28, T70, 97,105, 52, 64,129, 
85, 71,163, 35,221, 81,175, 58,195, 92,249,206,186,197,234, 
44, 83, 13,110,133, 40,132, 9,211,223,205,244, 65,129, 77, 
106,220, 55,200,108,193,171,250, 36,225,123, 8, 12,189,177, 
120,136,149,139,227, 99,232,109,233,203,213,254, 59, 0y 29, 
242,239,183, 14,102, 88,208,228,166,119,114,248,235,117, 75, 
49, 68, 80,180,143,237, 31; 206,219,153,141, 51,159, 17,131, 


1989 


2, 
15, 
38; 
82, 
74, 
57; 
10, 
20, 


/*The routine MDINIT initializes the message digest context buffer md.*/ 
/* All fields are set to zero. 
void MDINIT (md) 

struct MDCTX *md; 


{ 


} 
/* 
/* 
/* 
/* 


int. iy 

for (i=0;1i<16;i++) md->D[i] = md->C[i] = 0; 
md->i = 0; 

md->L = 0; 


The routine MDUPDATE updates the message digest context buffer to 
account for the presence of the character c in the message whose 
digest is being computed. This routine will be called for each 

message byte in turn. 


void MDUPDATE (md, c) 
struct MDCTX *md; 
unsigned char c; 


{ 
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register unsigned char i,j,t,*p; 

/**** Put i in a local register for efficiency ****/ 
i = md->i; 

/**** Add new character to buffer ****/ 
md->D[16+i] = c; 
md->D[32+i] = c ^ md->D[i]; 

/**** Update checksum register C and value L ****/ 


md->L = (md->C[i] ^= S[OxFF & (c ^ md->L)]); 
/**** Increment md->i by one modulo 16 ****/ 
i = md->i = (i + 1) & 15; 
/**** Transform D if i-0 ****/ 
if (i == 0) 
{ t = 0; 


for (j20; j«18; j++) 


ay 


*/; 
aed 
*7/ 
*/ 


(/*The following is a more efficient version of the loop:*/ 


/* for (i=0;i<48;i++) t = md->D[i] = md-»D[i] ^ S[t] 
p = md->D; 


for (i=0;1i<8;i++) 
{ t = (*pt* *= S[t]); 
t = (*ptt+ ^= S[t]); 
t = (*ptt+ ^= S[t]); 
t = (*pt* ^= S[t]); 
t (*pt++ ^= S[t]); 


go 
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} 


t = (*pt+ ^= S[t]); 
} 
/* End of more efficient loop implementation */ 
to- t4 9; 


} 


/* The routine MDFINAL terminates the message digest computation and */ 
/* ends with the desired message digest being in md->D[0...15]. */ 
void MDFINAL (md) 

struct MDCTX *md; 

{ int i,padlen; 


/* 


/* 
/* 
/* 
/* 


for 


} 


pad out to multiple of 16 */ 

padlen = 16 - (md->i); 

for (i=0;i<padlen;i++) MDUPDATE (md, (unsigned char) padlen) ; 

extend with checksum */ 

Note that although md->C is modified by MDUPDATE, character x], 

md->C[i] is modified after it has been passed to MDUPDATE, so */ 

the net effect is the same as if md->C were not being modified.*/ 
(i=0;i<16;i++) MDUPDATE (md,md->C[i]); 


[RR KKK KKK KKK KKK KKK KK KK KK KK KK OK KKK OK KR KK OK OK OK ckckck KK / 


/* End of message digest implementation A 
[RR KKK KKK KKK KKK KKK KK KKK OK KKK OK KK OK kckckckckck ck ckck ck kck ck ck ck ck kckck kc k kk / 
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